Dangling pointers (also referred to as wild pointers) in computer programming are pointers that point to memory that has already been freed. Dangling pointer typically arise when an object is deleted or deallocated, without modifying a value associated with a pointer referencing the object, such that the pointer after the object being deleted or deallocated is still pointing to a memory location of the deallocated memory. A system may reallocate the previously freed memory location to another object or even to another process. If the original program (software) dereferences the dangling pointer, unpredictable behavior may result, as the memory location may now contain completely different data. A disadvantage is that if the program writes data to memory pointed by a dangling pointer, as silent corruption of unrelated data may result, leading to subtle bugs that can be extremely difficult to find, or cause segmentation faults or general protection faults (Windows), and in particular if the overwritten data is bookkeeping data used by the system's memory allocator, this corruption can cause system instabilities. Hence detecting dangling pointers becomes a critical part of runtime memory analysis.
In many programming languages, and in particular the C/C++ programming language deleting an object from a memory location does not alter any associated pointers. The pointer still points to the memory location where the object or data was, even though the object or data has since been deleted and the memory may now be used for other purposes, thereby creating a dangling pointer. Other methods of creating dangling pointer for example include, the use of uninitialized pointers or pointers to a stack frame that have been popped off the runtime stack and hence no longer valid, or inappropriate pointer casts, or inappropriate pointer arithmetic etc.
A further frequent source of creating dangling pointers is a jumbled combination of a malloc( ) and a free( ) library call. Typically, in such cases, a pointer becomes dangling when the block of memory or the memory location that the pointer points to is freed. One way to avoid this is to ensure that the pointer back is set back to null after freeing the memory location.
Further, a common programming misstep that creates a dangling pointer is returning an address of a local variable. Since local variables are deallocated when a function returns, any pointers that point to local variables of that function will become dangling pointers once the stack frame is deallocated. This may occur in a non-trivial way also, such as an address of a local variable is passed as an argument to a method, which is perfectly valid. But later, reference made to a called method or another method directly or indirectly, stores this address in heap, if this heap location containing the address the local variable is used after the stack frame containing the local variable has been de-allocated.
A tool like IBM™ Rational Purify™ is configured to identify dangling pointers to memory locations/regions in a heap by using a deferred-free approach and intercepting methods calls such as malloc and free in the program. Intercepted free calls typically do not free the memory regions immediately; instead such calls adds the memory region to an available free queue and marks the memory region that was freed as invalid. Maintaining a free queue ensures that any future malloc calls (at least the immediate future ones) will not overlap with the recently freed memory regions. Since the freed memory regions have been marked as invalid, references to those memory regions will be detected as ‘Free Region Reads’ and are hence dangling pointers referring to the heap memory. In addition tools such as Valgrind, Mudflap, Addrcheck, Helgrind, LLVM etc., can also be used to detect uses of dangling pointers, each having its own advantages and disadvantages.
A disadvantage is that dangling pointer bugs are frequently security holes similar to buffer overflow bugs. For example, if the pointer is used to make a virtual function call, a different address (possibly pointing at exploit code) may be called due to the vtable pointer being overwritten. Alternatively, if the pointer is used for writing to memory locations, some other data structure may be corrupted in the process. Even if the memory is only read once the pointer becomes dangling, and can lead to information leaks (when data is placed in the next structure allocted) or a privilege escalation (if the now-invalid memory is used in security checks).
Without a way to improve the method and system of performance problem localization, the promise of this technology may never be fully achieved.